A wide variety of multimedia devices is incorporating the ability to receive and process picture data. Multimedia devices that use picture data generally need to encode and decode the data in order to transmit and receive the encoded data across various transmission mediums. Picture data is generally displayed as a set of pixels to fill the display screen. Processing of the overall set of pixels is performed on a block-by-block basis, with each block often referred to as a MacroBlock.
For transmission purposes, the picture data is generally transformed from the spatial domain to the frequency domain, via a discrete cosine transform (DCT) device, or the like. A scan pattern is applied, and the data is quantized (or compressed). FIG. 1A shows an illustrative representation of an N×N data block 100, in this case an 8×8 block, being fed into a quantizer 102 to thereby provide compressed data 104. While any variety of color models might be used for processing the video data, FIG. 1B shows a YUV color model 110, also referred to as YCbCr. Initially configured for PAL analog video, this model is now used in CCIR-601 standard for digital video. In this standard, the color images are encoded as triplets of values, wherein the Y value represents the main image, with the U and V values representing color difference signals. The 4:1:1 representation 112 shows that 4 data blocks 114, 116, 118, and 120 (i.e., 4 8×8 blocks) are associated with the Y component, and 1 data block (8×8) each 122, 124 are associated with the respective U and V components.
One important aspect of the quantizer is to compress the incoming data. Compression schemes are generally regarded as (a) lossless, wherein no data is lost, or (b) lossy, wherein some information is lost in compression, but it does not appreciably affect the end visual result. Lossy compression is more commonplace, as any savings in the number of bits will result in a more efficient transmission. If data is considered higher in frequency, then this indicates a significant change from one pixel to the next. In contrast, lower frequency data indicates that the pixels are not varying much across the block. In certain situations, a person's eye is considered to be more sensitive to the loss of higher frequency data, as the resulting picture has lost significant information between the pixel transitions. In still other situations, a person's eye might be considered to be more sensitive to the loss of lower frequency data.
FIGS. 2A and 2B show one common approach associated with run length coders. In FIG. 2A, the 8×8 block 202 is shown arranged so that the low frequency data is in the upper left half, and the high frequency data is in the lower right half. The data is then divided by a known scaling factor 203 (shown here as integer 32) to produce integer results 204, wherein the values are rounded down to the nearest integer, including zero. Accordingly, the upper left half of the block is filled with zeros, which represents the low frequency data. The lower right half of the block contains scaled value representations of the remaining high frequency data. FIG. 2B shows a contrasting example where the data block 206 contains significant lower frequency data in the upper left half of the data block, and a reduced amount of higher frequency data in the lower half of the data block. After dividing by the scaling factor 207, the higher frequency data has been rounded-down to zeros and certain lower frequency components remain.
FIG. 3 next shows a representation of a run level code 302 that takes advantage of the rounded-down zeros that were generated in the examples above. The code is represented by a series of zeros followed by a particular data value 304. By making as many of the values as possible equal to zero, then the representation of the bits can be significantly reduced. This run level code can then be used by a transmission device 306, which might include a variable length encoder (VLC) or the like, in order to facilitate modulation and transmission across any of a variety of transmission mediums.
Upon receipt by a receiving device, the picture data must thereafter be decoded for display on a video device. The decoding will be performed by a device that performs both inverse quantization (IQ) and inverse transform (IT) operations. For instance, FIG. 4 shows a pairing of representative IQ and IT devices 400. In the IQ device 402, the coded signal is received by a run level decoder 404 to discern patterns of code in the run level signal. An inverse scan 406 is thereafter applied to re-arrange the data into a desired format. Compression techniques have earlier been applied to the data, so dequantization (or inverse quantization) 408 is performed to decompress the data.
After the IQ block, an IT block 410 is shown, wherein a two-dimensional inverse transform is performed via the use of first-dimensional inverse transform 412, a column-row RAM device 414, and a second-dimensional inverse transform 416. This IT device might be hardwired according to different coding standards being used, or programmable to accommodate different standards. An example of a programmable IT device can be found in the above referenced application entitled “Inverse Discrete Cosine Transform Supporting Multiple Decoding Processes.”
Depending upon the coding standard being employed, the IQ block might need to perform additional processing upon the data after any of the various stages have been completed in the IQ process. Prior implementations have necessitated the addition of algorithmic steps—in the hardware and software—to be performed by the IQ block (or associated hardware). For instance, certain coding standards might require integer lifting or adaptive lifting to be performed on the data among any of the IQ processing steps, i.e., decoding, inverse scanning, and/or dequantization. Still other standards (i.e., MPEG4) might require inverse DC & AC prediction, or the like.
The ordering of the steps in the IQ block can also become particularized to certain coding standards. In prior implementations, each of the IQ process steps is generally performed—as a matter of implementation—regardless of whether or not each inverse process is even needed. Such additional processing tends to reduce performance of the overall system and increase power consumption. Hence, prior implementations of an IQ block are oriented around a particular coding standard and are not very versatile in handling the inverse quantization of a variety of different coding standards.
Accordingly, what is needed in the field is an inverse quantizer that is designed to be highly configurable and flexible in order to support a large number of coding algorithms. The inverse quantizer should be designed in such a way that a central processor can intervene between functions in the IQ process, in case a particular decoding algorithm requires software processing of some aspect of the algorithmic steps performed by the IQ block.